initial commit to add launchpad and mission control into QMK. #4762
Conversation
|
Looking at https://www.usb.org/sites/default/files/hutrr77_-_desktop_controls_0.pdf, the keycodes I am using should work. Also, I think that I have done everything that grota did. Not sure as to why it fails to compile. |
|
I think it's because in the enum KC_MISSION_CONTROL ends up having the value 0xC0 (it's the 16th from KC_MEDIA_EJECT). Not sure how the policy should be here. |
|
yeah, I am just confused at this point. it SHOULD work. But it doesn't. I mean, it works in the official docs! |
|
No, I mean that just looking at the output of the travis build I think that KC_LAUNCHPAD ends up having the value 0xC0 in the enum like its follower KC_FN0 which might messes things up. |
|
There is now only one free spot left after the screen brightness keycodes ( If you're looking for a way to make your keyboard more Apple-y, have a look at #2179 where I proposed adding the actual Apple Fn key. Unfortunately there is something of a drawback to it (you have to use an Apple VID/PID, and modify the QMK internals a little) so for legal reasons it wasn't implemented officially, however there is a diff if you want to follow along. |
|
@drashna it seems as though we could free up more space by replacing instances of case KC_FN0 ... KC_FN31:
action.code = keymap_function_id_to_action(FN_INDEX(keycode));
break;
// ...
case QK_FUNCTION ... QK_FUNCTION_MAX: ;
// Is a shortcut for function action_layer, pull last 12bits
// This means we have 4,096 FN macros at our disposal
action.code = keymap_function_id_to_action( (int)keycode & 0xFFF );
break; |
| @@ -194,6 +197,8 @@ typedef struct { | |||
| (key == KC_WWW_REFRESH ? AC_REFRESH : \ | |||
| (key == KC_BRIGHTNESS_UP ? BRIGHTNESSUP : \ | |||
| (key == KC_BRIGHTNESS_DOWN ? BRIGHTNESSDOWN : \ | |||
| (key == KC_LAUNCHPAD ? LAUNCHPAD : \ | |||
There was a problem hiding this comment.
If the order matters, then launchpad should be last.
|
okay, that makes a little more sense. I assume that there is no way to get rid of fn0? Is it necessary in QMK? also thanks @drashna, it compiles now! however, mission control does nothing. Launchpad, unfortunately, outputs g now. I don't think that it is possible to add in launchpad and mission control without getting rid of fn0, which I don't think is possible. |
|
Removing the FN keycodes right now will break many keymaps which still use them. They must all be replaced with Also, the various HID descriptors currently only declare consumer usages up to 0x029C, which probably explains why you are still not getting the correct behaviour. |
|
Are we really limited to 255 keycodes? Can't we "expand" the cardinality or maybe use another "space"? |
|
Keycodes in QMK are actually 16 bits wide, but even then there are few gaps because a lot of QMK features take keycodes from the basic set as a parameter in the low byte. Have a look at quantum_keycodes.h ;) |
|
So are you saying to add those keycodes to quantum_keycodes.h @fauxpark? That does seem pretty interesting, but I am not sure as to how I would do that. |
|
I guess it is technically possible, but since your new keycodes are still part of the consumer page it's probably a bad idea to fragment it like that. My point was to show how crowded the keycode space already is, even with 16 bits. Huge chunks of it are taken up by things like Mod-Tap & Layer-Tap which interpret the lower 8 bits as a basic keycode, and some part of the high byte as a modifier or layer etc. The best way forward IMO is to remove the FN keycodes, but that will take a bit of work due to all the keymaps referencing them. |
|
wouldn't it be better to move all our Consumer Page keycodes into My rationale is as follows:
|
|
If you can find space for them, sure. For reference, here's what the space looks like right now (as far as I understand it): The big one is the Unicode feature that hogs all of the remaining keycodes when it's enabled. |
|
yep. Not right now because I have to study some things for work, but I'll look into it "soonish" 😄 |
|
@fauxpark just out of curiosity, I did not understand this segment here: |
|
It's just a side effect of how the modifiers are represented in keycodes, which unfortunately takes up those 256 keycode slots. They act exactly like unmodified keycodes because they have the "right modifier" flag set ( |
|
There are a number of merge conflicts here. Alternatively, is it okay if we close the PR? |
I am TRYING to add in Mission Control and Launchpad into QMK.
Description
I am following what @grota did in his addition of brightness controls in #4477.
As of right now, it is not working, and I cannot figure out why.
Types of changes
Issues Fixed or Closed by this PR
Checklist: